Typically, communications networks implement security via firewalls. Traditionally, firewalls are owned by the entity being protected and are operated by expert personnel. Consumer firewalls, such as software firewalls installed on personal computers (PCs) that connect to Internet via broadband (e.g., DSL), are owned and operated by the consumer who is generally not an expert and is ill-equipped to manage the firewall properly. This often results in considerable user frustration and improper firewall configuration (i.e., bad or non-existent security).
One solution to these problems is the deployment of network-based firewalls placed in telecommunications provider networks that provide customers with experts who use appropriate methods and policies to manage the network-based firewalls. The telecommunications providers could offer this support to consumers as a service so that they do not have to try to implement and manage their own firewalls. However, network-based firewalls lack the ability to be reliably aware of exactly which applications are attempting to communicate through them. Therefore, the existing network-based firewalls are restricted to filtering based only on the application-transmitted packets and packet types traversing the network, which are detectable as these pass through the firewall. Thus, the network-based firewall can provide inbound protection, in terms of filtering packets from the Internet, but cannot provide sufficient outbound protection, resulting in what is known as a “leaky” firewall.
“Leakiness” encompasses two major problems. First, the firewall cannot stop a virus, Trojan, or other mal-ware from pretending to be a common “allowed” or “authorized” application (e.g., a web browser) and thus communicating without hindrance to nefarious entities out on the Internet. For instance, a Trojan could easily monitor keystrokes, collect user identification and passwords or other sensitive information, and then surreptitiously provide that information to collector web sites or servers in foreign countries beyond the reach of law enforcement. Thus, by using the Hyper Text Transfer Protocol (HTTP) or others allowed for web surfing, the Trojan would circumvent firewall filtering since the firewall must allow http to pass unhindered.
Second, it is difficult to configure the firewall properly without being able to filter on applications. The user often does not know, and cannot know, exactly what packet types or protocols applications use. Especially with a network-based firewall, which is remote from the host, it is difficult to determine the exact packet/protocol filtering to use, even for expert administrators. The problem is compounded with new applications, which may use a number of protocols or ports (e.g., networked games), and may change ports during operation (e.g., port-agile applications such as video over IP (VoIP)).
Thus, heretofore-unaddressed needs exist for a solution that addresses the aforementioned and other deficiencies and inadequacies.